home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
InfoMagic Standards 1994 January
/
InfoMagic Standards - January 1994.iso
/
inet
/
ietf
/
tnfs
/
92may.min
< prev
next >
Wrap
Text File
|
1993-02-17
|
6KB
|
188 lines
INTERIM_MEETING_REPORT_
Reported by Fred Glover/DEC
Minutes of the Trusted Network File Systems Working Group (TNFS)
May 1992
Agenda
o Reviewed the recent modifications to the TNFS document (TNFS-001.2.02)
o Reviewed the TKM document (TNFS-006.01.01)
o Reviewed implementation status and issues
o Discussed Lock Manager impact
o Discussed TNFS auditable events
TNFS Document Review
The IETF TNFS document has been available for comments in the IETF Draft
Directory and TNFS archive since July, 1991. During the May meeting,
the Working Group made ``final'' wordsmithing modifications, and edits
to the document. This concludes the work planned for the TNFS
specification, and the next steps are to transition the document to
Proposed Standard. Trusted Systems technology providers are encouraged
to commence implementation based upon the current TNFS draft.
Final updates to the TNFS document include:
o Add vendor specific token to directory response structure, set
label procedure arguments.
o Change the arguments to the MLD procedure to reference operations
rather than flags.
o Add explicit indication within ACCESS and file open sections to
identify conditions in which a client caching security attributes
must revalidate the rights of a given client application (i.e., by
calling ACCESS).
o Add rationale indicating why security attribute tokens are not
required to be included in the read directory response structure.
We spent some additional time discussing auditing. Conclusions include:
o Some environments may require that both client and server auditing
is enabled in order to ensure full audit of events such as:
- First read (server audits; may need to check audit id and XID
1
in order to identify actual issuing PID if that is required).
- Floating of objects (server only; client can't see).
- Server override of privileges (server only; client can't see).
o The transaction ID is a possible ``key'' which can be used to
correlate a client request with the server side procedure.
An updated document will be placed in the IETF and TNFS archives after
an ``email'' review of the updates has been completed. In addition,
Fred will contact our IETF Area Director, Dave Borman, to understand our
``next steps'' in the standardization process.
Token Manager Review
The TKM document was also reviewed. It now contains an attribute to
token procedure. The following updates will be made to the document:
o Editorial (wordsmithing).
o Length field added to string arguments.
The updated TKM document will be placed into the IETF Draft Directory
(informational RFC) and the TSIG TNFS archive.
We have been reviewing both the TKM and MAC6 token mapping proposals.
Our current recommendation is for each of these to be submitted as IETF
informational RFCs. One of these would be identified to become the
actual standard, once all of the IETF/TSIG token mapping requirements
were understood and were accommodated by at least one of these
proposals. We recommended that a new working group be formed which
would assume the responsibility of collecting the requirements,
reviewing all of the proposals, and making recommendations.
Implementation Status, Issues
The Working Group reviewed the progress of current implementation
efforts. Two implementations are very ``close'' to conformance with the
current version of the specification. We discussed testing
possibilities for the end of this year. We have already identified a
test plan, a set of ``non-mapped'' security attributes for testing, and
a modified test routine to be used with the Connectathon test suite. An
update of the tnfs.h file, describing all of the TNFS procedures and
data structures, will be placed into the TSIG/IETF archive to facilitate
development of additional implementations.
Lock Manager Update
Charlie Watt recently completed a review of the NFS lock manager and
suggests that no changes appear to be required to the lock manager to
2
work in the TNFS environment. This confirmed the results of an earlier
Working Group discussion and closes an action item. Thanks Charlie!
TNFS Auditable Events
We started the discussion of TNFS auditable events at this meeting.
Mark Saake will be developing a document which describes this area.
Conclusions reached at this meeting:
o The TNFS Group will focus on server side (i.e., protocol procedure)
auditable events; we will expect that POSIX will identify the
client side (i.e., application, API based) events and formats.
o When the server receives a TNFS request, it can identify:
- Host address (and thus host)
- File handle
- Export structure
- Procedure number
- Version number
- Credential information (ID info); result of subsequent
authorization check (i.e., pass or fail).
- Log entry and exit status of each called TNFS server procedure.
Next Meeting
The TNFS Group will plan to meet jointly with IETF and TSIG at the July
meeting in Boston. At that meeting, we plan to:
o Present a summary to interested IETF attendees during a designated
two hour time slot.
o Review the ``final'' version of the TNFS documents (updated
documents placed into the TNFS archive and IETF Drafts Directory:
Fred, Fran, Carl, Ali).
o Review the interoperability test opportunities, plans (all).
o Review NFS test suite extension for TNFS (Fran).
o Identify conforming implementations to support our request to
transition our TNFS document (all).
o Review identification of auditable TNFS events (Mark).
o Place ``tnfs.h'', test plan, test attributes into TNFS archive
(Fred).
3
The July meeting is planned for the 13th-17th at the Hyatt Regency in
Cambridge, Massachusettes.
Attendees
Lida Carrier lida@apple.com
Fran Fadden fran@decvax.dec.com
Jonathon Fraser
Fred Glover fglover@zk3.dec.com
Ali Gohshan
Brian Hardy
Mark Saake saake@netcom.netcom.com
Carl Smith cs@eng.sun.com
T.T. Tao
Charles Watt watt@sware.com
4